In general, support of automated (or programmed) upgrades from one version of a software product to the next is a well-known and often-practiced activity. In performing upgrades of a software product, both the software data model and associated data require updating.
The data model of a product refers to the underlying structure and modeling of customer data. The data model includes type (or class) definitions, allowed relationships among types, policies for accessing, creating, modifying and deleting customer data, object state definitions and allowed state transitions, and actions which can take place. In other words, the data model defines the rules by which application data can be created, represented, modified, and acted upon.
The ability to automate upgrades depends on the degree of stability of a product's data model. Challenges in performing an upgrade are introduced if key elements of a product's data model change between versions. If a products data model changes with an upgrade, the installer for the new version must apply those changes to the data model and data of the earlier version of the product. A transformation is required—not only to the new data model, but also of the customer's existing data so that it can be consistent with the new structure expected by the new version of the software.
Conventionally, such data model and data transformation has often been handled explicitly through a series of programmed steps, written manually by a developer in a script or programming language, and may be incorporated into an upgrade installer. Manual development of software to handle this has been used because it has been assumed that automation is too difficult to justify the effort since the required changes are different for each customer-specific release. However, manually writing such code is often a tedious and time-consuming process.
In some aspects of the conventional arts, tools have been developed to analyze and display the differences in two versions of a data model (corresponding to two different product releases.) However, the majority of these tools are limited to identifying and presenting information; no command or other executable output may be generated for migrating one representation of the data model (and corresponding data) to another. An example is described by United States Patent Publication No. 2009/0307650 A1 which performs analysis and presents the results, but does not act on those results.
Other aspects of conventional arts have taken the next step of execution in order to carry out a data model migration as part of an upgrade. An example is described by United States Publication No. 2009/0198727 A1 which utilizes a trace log of all changes that have taken place in an initial migration of a data model from one state to another. These recorded trace steps are then converted into a corresponding series of executable steps. These steps can then be used to repeatedly perform the exact same data model upgrade (for example, in an installation script) in repeated deployments.
Another example of an executable set of steps to perform a data model and data migration is provided through a Dassault Systemes S.A. tool provided with its Enovia platform referred to as “Spinner”. Spinner may be used to load or dump data models from an application and can be used to view or modify its data model. It is typically used to install a data model into a system database. Additionally, it has a utility to compare two different data models and produce a list of differences (a “delta”) between them. This delta can then be converted to a series of steps to migrate a data model from the original state to a desired target state.
Accordingly, conventional tools analyze (or record) the differences between data models and can produce executable output that can be used to align the data models. However, these conventional tools may be limited to working only from specific a priori states of the data model. That is, the data model from which a given upgrade takes place must exactly match a predefined state (for example, a specific previous version of a software product). This means the tools can fail if any custom changes have been made to the data model between upgrades. Custom changes to a data model put it (and its corresponding data) into a state that does not match the expected state of such an installation tool. Without a matching initial state, an upgrade can fail using these conventional tools.
Custom changes to the data model are not infrequent. Sometimes a vendor is involved in these customizations. If that that case, the vendor may have sufficiently accurate records of the custom changes to allow the vendor to perform an upgrade of data and the data model or the customer may be trained to make data model changes (also known as “schema changes”) independent of the vendor. This significantly compounds the problem of performing upgrades due to the analysis that must be done to assess and document the state of the current data model, how the data model differs from the product's original data model, and how a path forward can be established. Consequently, upgrades of customized products are typically very costly in that an upgrade often requires a significant amount of manual software modification to accommodate the customizations that have been made to the data model.
Significant cost savings can be realized if an automated means of analyzing customizations to a data model can be performed. Still further cost savings can be realized if the analysis can be used to automate the migration of custom features to an upgraded product release by taking the custom data model into account.